QRZ! Ham Radio 8/QRZ Ham Radio Callsign Database - Volume 8.iso/pc/files/mac/hfpcktrn.hqx/HF Packet tutor/hf_packet.txt

Text File | 1993-06-28 | 18KB | 341 lines

               A BRIEF TUTORIAL ON HF PACKET OPERATION
                       by Norm Sternberg, W2JUP

1.   TNC PARAMETER VALUES

     RULE 1: DON'T USE THE FACTORY DEFAULTS IN YOUR TNC

     The values stored in your TNC's EPROMs are totally unsuitable for HF
     packet operation; they are tailored for the average VHF case.  Here is a
     set of recommended "non-default" parameter values for general purpose HF
     operation on 40, 20 and 15 meter packet operation.

          MAXFRAME 1 to 2
          PACLEN 32, 64 or 80
          TXDELAY 40 or 50
          FRACK 6, 7 or 8

     MAXFRAME

     Choose a lower setting for poor conditions, a higher value for better
     conditions.  We have very strong mathematical and experimental evidence
     (papers by Phil Karn and others) that MAXFRAME 1 provides better long-
     term throughput even on VHF!

     If you send FOUR frames in one packet and the distant station ACKs only
     frame #1, then you're going to resend frames #2, #3, and #4.  If he ACKs
     frames #2, #3 and #4 but bombs #1, you're going to resend all four of
     them again anyway.  What's the point in cluttering the channel with two,
     three or four un-ACK'ed frames when the first one hasn't been accepted?

     Each frame imposes a fixed "overhead" on the packet.  This "overhead" is
     the synchronization, timing, clocking, control and address information
     stuff that you DON'T type; the stuff that makes the protocol work.  The
     simplest frame you can send has at least 19 bytes (152 bits) of overhead.
     Each BIT of each BYTE is tested by the error correction process.

     Unless you have a definite need to maintain a specific document format,
     don't waste bandwidth inserting blank lines because you think it may
     "look good" on the other station's screen.  If you're operating in the
     CONVERSE mode as most people tend to do, your packet frame is actually
     sent by the CARRIAGE RETURN or ENTER key.

     That single CR/LF you type to make a blank line creates a frame that has
     exactly the same overhead as a frame that has 80 typed characters.  This
     "overhead" is the packet protocol stuff like the sync, callsigns and con-
     trol information - stuff that you don't see, that conveys no "user" in-
     formation.  Every blank line must be ACK'ed just the same as the fully
     typed lines.  (It hurts to see a link time out retrying a blank line.)

     PACLEN

     Choose a lower setting for poor conditions, a higher value for better
     conditions.

     This is the number of typed characters that makes ONE frame.  The lower
     the number of characters or bytes in the frame, the higher the mathemat-
     ical probabilities of getting through without taking a hit.

     Each byte in the overhead mentioned above has eight bits.  Each of the
     characters you type has eight bits.  If any one of those bits in any one
     of those overhead bytes (or in your typed characters) takes a noise hit,
     then the error correction process fails, and the whole frame is thrown
     away.

     Let's say that W2JUP is directly connected to W2HPM and sends the simple
     line:

          Hello, Joe, how are you?>>

     That small packet frame actually consists of at least 20 bytes (160 bits)
     of overhead, plus 27 bytes (208 bits) of your typed data, a total of 376
     bits.  If any one of those 376 individual bits is trashed at any point in
     the link during transmission, then the entire frame is thrown away by the
     receiving station.

     Now let's assume that you're still using the factory-default value of
     PACLEN, 128 bytes, and that you're NOT typing any CR/LF so that your TNC
     is automatically sending the packet at your 129th typed character.  Your
     frame might look like this:

     Joe, I wanted to let you know that I wouldn't be able to go to the club
     meeting tomorrow night and you'll have to get a ride from

     The same simple arithmetic tells us that you've just sent 20 bytes of
     overhead, plus 128 bytes of the characters you've typed, resulting in a
     frame that has 20 + 128 * 8 = 1184 bits.

     Simple common sense says that the chances of getting 1184 bits through
     the link "unharmed" - are much lower than getting only 376 bits through
     without damage by the typical noisy HF radio environment.  Now - if you
     happen to be operating with the factory-default settings (as your TNC is
     shipped from the factory):

          MAXFRAME 4
          FRACK 3
          PACLEN 128

     Let's look at MAXFRAME first.  Arithmetic tells us that you've just sent
     a packet of FOUR frames, each one containing 1184 bits, totalling 4736
     bits. The chance of ALL 4736 bits surviving the journey in typical HF
     conditions is a wee bit small.

     We're limited by Part 97 to a maximum 300 bit-per-second data rate on HF
     packet.  At 300 bits per second, each BIT of each BYTE (or character) has
     a duration of 3.3 milliseconds.  You can see that it doesn't take much of
     a noise pulse to smear one of those many bits and thereby kill an entire
     frame.  Have you ever measured the length of a single pulse from either
     the "Woodpecker" or your local power line noise?

     Now, let's look at FRACK.  The FRACK timer sets the amount of time that
     your TNC will wait for an ACK after the instant your PTT keys your rig.
     Contrary to a common misunderstanding, FRACK time is NOT counted from the
     end of your burst; it's counted from the beginning.

     Let's assume you're still using the factory supplied default values

          FRACK 3 (3 seconds)
          TXDELAY 30 (300 milliseconds).

     Let's say that you send our sample short line shown above:

          Hello, Joe, how are you?>>

     That packet frame contains 376 bits of stuff.  More arithmetic:

          376 bits @ 300 bits per second    = 1.25 seconds
               300 milliseconds TXDELAY     = 0.30 seconds
                           Length of burst  = 1.57 seconds
                     minus FRACK delay      = 3.00 seconds
         Available response window for ACK  = 1.47 seconds

     This appears to be logically possible - but is it really?  Is this
     enough time for the other station to send you the ACK you need?

     The other station's TNC must send an ACK whose minimum length will be 20
     bytes or 376 bits.  If he's using a slightly lengthened TXDELAY (say 400
     milliseconds, a longish DWAIT of 320 milliseconds, a RESPTIME of 5 (500
     milliseconds), or if his TNC hears anything on the channel and delays the
     ACK for even a few hundred milliseconds, we have an interesting problem.

     Let's assume that the other station's TNC received a valid frame from
     your system, the channel is clear, and his TNC is going to send the ACK
     back to you.  Now we've got a very cute "CATCH-22" situation:

          376 bits @ 300 bits per second    = 1.25 seconds
          Distant station's TXDELAY         = 0.40 seconds
          Distant station's DWAIT           = 0.32 seconds
          Distant station's RESPTIME        = 0.50 seconds

      TOTAL DELAY before other station's end-of-data  = 2.47 seconds

     Remember that your system won't know if his ACK is valid until your TNC
     has received and decoded his entire frame.  The combined delays intro-
     duced at his end now approach your FRACK time.  You can't decode and val-
     idate his ACK before your FRACK timer runs out.  Your TNC RETRYs your
     frame because the other station's ACK didn't arrive on time.  And all
     this relates to his sending an ACK frame of only 20 bytes.

     Now that we've had a taste of timing concepts, let's see why HF packet
     doesn't work and what happens if you're still using the factory-default
     values:

          MAXFRAME 4
          PACLEN 128
          FRACK 3

     Our arithmetic said that you would send a packet of four frames, each one
     containing 1184 bits, totalling 4736 bits.

          4736 bits @ 300 bits per second   =  15.79 seconds
          300 milliseconds TXDELAY          =   0.30 seconds
                           Length of burst  =  16.09 seconds
                           FRACK delay      =   3.00 seconds
         Available response window for ACK  = minus 13.09 seconds

     You cannot fit a 16-second burst into a 3-second FRACK window.  Your
     FRACK timer expires before you've finished sending the packet!  This is
     not going to work!

     Now, let's use the same arithmetic to see how our suggested values fit in
     here.

          MAXFRAME 1 (Only ONE un-ACK'ed frame allowed on the air)
          PACLEN 64  ((64 * 8) + (20 * 8))  = 672 bits
          FRACK 6    (6 seconds)
          672 bits @ 300 bits per second    =  2.24 seconds
                  300 milliseconds TXDELAY  =  0.30 seconds
                           Length of burst  =  2.54 seconds
                              FRACK delay   =  6.00 seconds
       Available response window for ACK    =  3.46 seconds

     This will work.  Your single frame packet burst of 20 bytes of overhead
     and 64 bytes of your typed data adds up to about 2.5 seconds.  About 3.5
     seconds remain available as the interval during which you must receive
     the ACK from the other guy before your TNC will retry the frame.

     Below 28 MHz you're limited to 300 bits per second.  On VHF you've been
     using 1200 bits per second.  Everything on HF takes FOUR TIMES LONGER to
     send, and FOUR TIMES LONGER to receive.

     TXDELAY

     Don't assume that TXDELAY relates ONLY to your radio's switching times.
     It also relates to the switching and other timing factors in the other
     station's radio.  In our real world of HF packet radio, TXDELAY relates
     to the radios at both ends of the link.

     Nearly all phase-locked-loop synthesized radios have some measureable
     "settling time".  This delay is introduced by some PLL frequency setting
     systems when switching from transmit mode to receive mode and vice-versa.
     We also note that many HF transceivers have a significant delay - even
     with "fast" AGC.  This additional delay occurs while the receiver's AGC
     circuit is "relaxing" and returning the receiver to full sensitivity.

     One more cause of delays appears when the sending station uses AFSK in
     the single-sideband mode.  Some operators are not careful to avoid
     driving the transmitter into ALC action.  ALC (Automatic Level Control)
     tends to reduce the transmitter's power output at keyup time and, if
     excessive, can actually destroy the first few bytes of the transmitted
     packet frame.  Those first bytes of each packet frame are the FLAG field,
     the information that marks the beginning of the frame and provides timing
     or synchronization information to the other station's TNC.  If the flag
     is smeared during transmission, the receiving TNC can't use that frame
     and throws away whatever it receives after it.  In addition, the more
     sync you have on the front of each frame, the higher the probability that
     the other station's TNC will successfully decode your frame in conditions
     of noise and propagation effects.

     Extra flag also seems to help combat the effects of multipath and select-
     ive fades.  Don't fall for that "Too much TXD cuts down my throughput"
     nonsense.  If the other station doesn't decode your flag correctly, then
     all the bytes after the sync are trashed; the frame is thrown away.  So
     much for your "throughput".

2.  FREQUENCY CONTROL AND STABILITY

     RULE 2: HF PACKET DEMANDS PRECISE OPERATING FREQUENCY CONTROL!!

     You've operated VHF packet without problems, so you've probably ignored
     your TNC's transmitted tones and calibration.  You've probably devoted
     the same benevolent neglect towards your TNC's demodulator calibration.
     You connect to your buddies and to the local BBS; your rule has been "if
     it ain't broke, don't fix it".

     On FM, the the tones you receive are directly generated and controlled in
     the other station's TNC and vice-versa.  Your TNC's tones are transmitted
     directly, unaltered, by your FM transmitter and received unaltered by the
     other station's receiver.  Your synthesized radio's LED frequency display
     tells you you're on the same frequency as the other station.

     But HF packet is a different story.  The tones produced by your TNC may
     no longer be the same tones that come out of the other station's radio.
     The frequency of the tones recovered from the other station's receiver
     depend on how the other station's operator tunes his receiver.  Whether
     you and the other station are using AFSK or direct FSK, the tones from
     the receiver will always be determined by receiver frequency tuning.

     Tuning accuracy on HF packet radio is generally more critical than in the
     other operating modes.  Tuning errors as small as 20 Hz can result in
     failure to decode packets successfully.  The more selective the receiver
     and the TNC's filters, the more critical the tuning accuracy.  Some IF
     filters can be too narrow to handle data at our usual HF packet rate of
     300 bits per second.  In general, IF filter bandwidths should be greater
     than 500 Hz for packet operation at 300 bits per second.

     HF packet operation also imposes greater demands for overall transmitter
     and receiver stability.  Unless the rig can hold frequency, plus or minus
     20 or 30 Hz for more than just a few minutes, you may drift right out of
     a useable HF link and "die" from excessive retrys.

     There are other interesting problems.  Unlike conventional Baudot, ASCII
     RTTY and AMTOR, packet signals use a data format called NRZI (non-return-
     -to-zero-inverted), which in effect ignores data sense (mark-space polar-
     ity).  On HF packet, you can use upper sideband or lower sideband equally
     well.  The only difference will be in the frequency shown on your rig's
     tuning display.  You can be on USB while your link partner can be on LSB.
     Your rigs will appear to be on different frequencies.  In general, most
     stations using AFSK tend to operate on LSB.  It's best to use the same
     sideband as the station you're working.

     To set up a schedule, or connect to a PBBS, or link in a network system,
     you can't always go strictly by the frequency displayed by most modern HF
     rigs.  There is no industry-wide standard as to the exact meaning of the
     numbers shown.  Some transceivers display the frequency of the suppressed
     carrier in SSB; some show the frequency when your rig is tuned to Mark
     (lower) tone, some show tuning for Space (higher) tone.  Some HF rigs
     even provide front-panel adjustment of the digital display to whatever
     the user wishes; carrier, USB, LSB, FSK either tone, etc.

     For the AFSK packet operator, this situation is somewhat complicated by
     the lack of an industry-wide standard for HF Mark and Space tones.  AEA's
     PK-64 and PK-232 TNCs use 2110 Hz as Mark and 2310 Hz as Space, about in
     the same range as the traditional RTTY tones at 2125 and 2295 Hz (plus
     and minus 15 Hz).

     Most licensed clones of the TAPR TNC-2 (including the AEA PK-80) use 1650
     and 1850 Hz for Mark and Space respectively.  TNCs using the AMD7910
     "World Chip" modem (including AEA's PK-87 and PK-88) provide a choice of
     1075 Mark and 1275 Space, or 2025 Mark and 2225 Space.

     When using AFSK, your rig's displayed frequency will literally depend on
     the tones being transmitted by the distant station, and also on the fre-
     quencies to which your TNC's demodulator and filters are tuned.  Check
     your TNC and transceiver operating manuals to determine what audio tones
     your TNC uses for Mark and Space, and how your rig's digital display re-
     lates to the received and transmitted frequencies.

     There are some subtle problems in HF packet radio.  You may see lots of
     interesting packet signals, send repeated connect requests - and nothing!
     You check your timing parameters; they're all what they should be.  You
     set AGC to "FAST", you verify that "ALC" is not active.  VOX is turned
     off, the rig is putting out power, the antenna is connected, everything
     appears "normal - and still nothing!  What can be wrong here?

     You've probably assumed that your rig is receiving and transmitting on
     the same frequency shown by your digital display.  This is not always
     true!  Some of the most-recent HF transceivers seem to have as much as
     200 Hz difference between the receive and transmit frequencies.  This is
     enough to guarantee your inability to establish and maintain a decent
     packet link.  Don't assume anything!  Be prepared to tweak your RIT/XIT
     controls to make the link work.  Be prepared to recalibrate your rig's
     reference oscillators if neede.  You may require either a good counter or
     a patient partner to determine how your rig is behaving and if you're
     really sending and receiving on the same frequency.

3.   CONCLUSIONS

     You too can work HF packet successfully.  Remember these general
     principles:

     o    Assume nothing
     o    Take nothing for granted
     o    Check everything twice
     o    Recognize that there are major operational differences between VHF
          and HF packet radio.
     o    Remember the two most-critical factors for success on HF packet:

          TIMING and TUNING

/30
W2JUP